FIG. 1 is a block diagram illustrating a UMTS (universal mobile telecommunications system) network structure.
Referring to FIG. 1, the UMTS system includes a terminal (user equipment (UE)), a UMTS terrestrial radio access network (UTRAN) and a core network (CN). The UTRAN includes at least one radio network sub-system (RNS). Each RNS includes one radio network controller (RNC) and at least one base station (e.g., node-B) managed by the RNC. At least one cell exists for each node-B.
FIG. 2 is a diagram illustrating a radio interface protocol architecture between a terminal and a UTRAN. As such, FIG. 2 depicts a radio interface protocol architecture based upon a 3GPP (third generation partnership project) radio access network specification between the terminal and the UTRAN.
Referring to FIG. 2, the radio interface protocol is horizontally arranged to include a physical layer, a data link layer, and a network layer. Furthermore, the radio interface protocol is vertically divided into a user plane for data information transfer and a control plane for signaling transfer. The protocol layers may also be divided into an L1 (first layer), an L2 (second layer) and an L3 (third layer) based upon the lower three layers of an open system interconnection (OSI) model.
The first layer or physical layer provides an upper layer with an information transfer service using a physical channel. The physical layer is connected to an upper layer called a medium access control (MAC) layer through a transport channel. Data is transferred between the MAC layer and the physical layer through the transport channel. Data is also transferred between different physical layers, i.e. between physical layers of a transmitting side and a receiving side, through the physical channel.
The MAC layer of the second layer provides an upper layer called a radio link control layer with a service through a logical channel. A radio link control (RLC) layer of the second layer supports reliable data transfer and performs segmentation and concatenation of a service data unit (SDU) received from an upper layer.
A radio resource control (RRC) layer at a lower portion of the L3 layer is defined in the control plane and controls logical channels, transport channels, and physical channels for configuration, re-configuration and release of radio bearers (RBs). A RB is a service provided by the second layer for data transfer between the terminal and the UTRAN. The configuration of the RBs includes defining characteristics of protocol layers and channels required to provide a specific service, and configuring respective specific parameters and operation methods. When the RRC layer of a terminal and the RRC layer of a UTRAN are connected to communicate RRC messages, the terminal is in an RRC connected state. However, if the RRC layer of the terminal and the RRC layer of the UTRAN are not connected, the terminal is in an idle state.
An upper layer of the RRC of the terminal commands the start of an RRC connection procedure. That is, the RRC of the terminal does not arbitrarily start the RRC connection procedure. Rather, the RRC of the terminal starts the RRC connection procedure upon receiving a command given from the upper layer of the RRC. The upper layer of the RRC notifies the RRC of the cause of the RRC connection using an establishment cause value.
An RRC state of the terminal and an RRC connection method are described below.
The RRC state indicates whether or not the RRC of the terminal has a logical connection with the RRC of the UTRAN. If the connection is made, the RRC state is an RRC connected state. However, if the connection is not made, the RRC state is an RRC idle state. When the terminal is in the RRC connected state, the UTRAN may recognize (e.g., may count) the existence of terminals within a cell, in order to control the terminal. However, when the terminal is in the idle state, the UTRAN may not recognize the terminal. Therefore, a core network manages the terminal within a location area or routing area unit. The location area or routing area unit is wider than the cell. The existence of the terminal in the idle state may only be recognized wider area unit, such as a location area or routing area unit. The terminal should therefore enter a connected state in order to receive general mobile communications services, such as voice or data.
When a user initially turns on the terminal, the terminal searches an appropriate cell and then remains in the idle state in the corresponding cell. When RRC connection is required, the terminal in the idle state transitions to an RRC connected state by establishing an RRC connection with an RRC of the UTRAN. The terminal in the idle state requires the RRC connection in cases such as uplink data transfer due to a user's attempt to make a phone call, or transfer of a response message with respect to a paging message received from the UTRAN.
As mentioned above, the terminal in the idle state performs an RRC connection procedure to establish an RRC connection with the UTRAN. The RRC connection procedure includes three steps of: sending an RRC connection request message from the terminal to the UTRAN, sending an RRC connection setup message from the UTRAN to the terminal, and sending an RRC connection setup complete message from the terminal to the UTRAN.
FIG. 3 is a diagram illustrating RRC connection between a terminal and the UTRAN.
Referring to FIG. 3, to establish an RRC connection for a calling attempt or a response to paging from the UTRAN, the terminal in the idle state sends an RRC connection request message to the UTRAN (S10, S11). The RRC connection request message includes an initial UE identity of the terminal and an RRC establishment cause. The initial UE identity is an inherent identity of the terminal which allows the terminal to be identified. The terminal sends the RRC connection request message and also drives a timer. If the terminal does not receive an RRC connection setup message or an RRC connection rejection message before the timer expires, then the terminal re-sends the RRC connection request message. The maximum number of times that the RRC connection request message is sent is limited to a set value.
Upon receiving the RRC connection request message from the terminal, the UTRAN accepts the RRC connection request of the terminal, as long as radio resources are sufficient, and sends an RRC connection setup message (e.g., a response message) to the terminal (S12). The RRC connection setup message includes an initial UE identity, a radio network temporary identity (RNTI), and radio bearer setup information. The radio network temporary identity (RNTI) is an identity of a terminal. The RNTI is assigned to identify a terminal in a connected state and is used when the RRC connection exists. The RNTI is used within the UTRAN.
After the RRC connection is established, the terminal communicates with the UTRAN using the RNTI instead of the initial UE identity. The initial UE identity is an inherent identity of the terminal and therefore is used by the terminal in the RRC connection procedure, instead of the RNTI, for security purposes.
Upon receiving the RRC connection setup message from the UTRAN, the terminal compares its own identity against the initial UE identity included in the RRC connection setup message to check whether the received message is for the terminal. If the check shows that the message is for the terminal, the terminal stores the RNTI assigned by the UTRAN and sends an RRC connection setup complete message to the UTRAN (S13). The RRC connection setup complete message includes performance information related to the terminal. If the terminal succeeds in sending the RRC connection setup message, the terminal establishes an RRC connection with the UTRAN and transitions to an RRC connected state (S14, S15).
The RRC connection procedure described with respect to FIG. 3 is performed upon the UTRAN's acceptance of the RRC connection request. However, if radio resources are not sufficient, the UTRAN may reject the RRC connection request. This scenario is described further below with respect to FIG. 4.
FIG. 4 is a diagram illustrating RRC connection rejection by the UTRAN.
Referring to FIG. 4, the terminal in the idle state sends an RRC connection request message to the UTRAN (S20, S21). Upon receiving the RRC connection request message, the UTRAN sends an RRC connection rejection message to the terminal, if necessary (S22). When the UTRAN sends an RRC connection rejection message to the terminal, including an initial UE identity and a rejection cause in order to notify the terminal of the reason why the RRC connection request has been rejected. The terminal receives the RRC connection rejection message and checks whether the message is for the terminal via the initial UE identity. If the RRC connection rejection message is for the terminal, then the terminal stops attempting RRC connection. However, if the initial UE identity included in the RRC connection rejection message is different from the initial UE identity of the terminal (e.g., the message is not for the terminal), the terminal discards the message and continues to wait for reception of an RRC connection setup message or an RRC connection rejection message.
Since terminals move from place to place, the UTRAN performs a counting procedure related to movement of the terminal. The movement of the terminal is considered in a situation where the terminal has sent an RRC connection request message and then moves to another cell before receiving a response from the UTRAN. Furthermore, the movement of the terminal is considered in a situation where the terminal has received an RRC connection setup message from the UTRAN and then moves to another cell before sending an RRC connection setup complete message.
In the first situation of where the terminal has sent an RRC connection request message and then moves to another cell before receiving a response from the UTRAN, the UTRAN may send a response message to the terminal. However, the response message is sent within the cell where the terminal sent the RRC connection request message. Therefore, the terminal may not receive any response from the UTRAN after the terminal has moved to another cell. Therefore, unless other actions are performed, the terminal may not establish any RRC connection in a new cell. Thus, having moved to another cell before receiving an RRC connection setup message, the terminal should construct a new RRC connection request message and send the newly constructed message to the UTRAN.
In the second situation where the terminal has received an RRC connection setup message from the UTRAN and then moves to another cell before sending an RRC connection setup complete message, because the UTRAN does not receive a response from the terminal regarding establishment of an RRC connection, the UTRAN may not complete information related to the terminal and environment configuration. Furthermore, upon determining that the terminal stays in the first cell, the UTRAN manages radio resources for the terminal within the first cell. Accordingly, unless other actions are performed within a cell to which the terminal has newly moved, the terminal may not establish an RRC connection. Therefore, the terminal should construct a new RRC connection request message and send the newly constructed message to the UTRAN.
FIG. 5 is a flow diagram illustrating an RRC connection establishment procedure by the terminal during cell reselection.
Referring to FIG. 5, to establish an RRC connection, the terminal in an idle state sends an RRC connection request message to the UTRAN (S30).
The terminal checks whether re-selection of a cell occurs while waiting for the reception of an RRC connection setup message from the UTRAN (S31, S32). If the re-selection of the cell occurs, the terminal compares a V300 value to an N300 value (S45). If the V300 value does not exceed the N300 value, the terminal sends an RRC connection request message to the UTRAN and then performs operations related to step S31. If the V300 value is greater than the N300 value, the RRC connection establishment procedure is completed. The terminal then increases a V300 value by 1 and then re-operates a T300.
In contrast, when receiving the RRC connection setup message from the UTRAN, the terminal begins configuration of a radio environment according to contents of the corresponding message and stops the T300. Once the radio environment configuration is completed, the terminal sends an RRC connection setup complete message and completes the procedure. However, if cell re-selection occurs before the RRC connection setup complete message is sent to the UTRAN (S35, S36), the terminal compares a V300 value to an N300 value (S34).
If the comparison result shows that the V300 value does not exceed the N300 value, the terminal re-sends an RRC connection request message to the UTRAN and then performs the operations from step S31. If the V300 value is greater than the N300 value, the terminal completes the RRC connection establishment procedure.
The V300 is a value for managing the number of times that the terminal sends an RRC connection request message in the current RRC connection establishment procedure. The terminal compares the V300 to the N300 to perform management allowing the RRC connection request message to not be sent as frequently as N300. The T300 is a timer used to prevent problems occurring as the terminal indefinitely waits for a response from the UTRAN under circumstances where the UTRAN may not send a response to the terminal. If the terminal does not receive a response from the UTRAN until the T300 expires, the T300 controls of the release of the RRC connection establishment procedure and/or transmission of a new RRC connection setup request message.
A multimedia broadcast/multicast service (MBMS) is described below.
The MBMS refers to a service that provides a plurality of terminals with a streaming or background service, using a downlink-dedicated MBMS bearer service (BS). An MBMS service includes at least one session, and MBMS data is sent to a plurality of terminals through the MBMS bearer service (BS) only while the session is ongoing.
The UTRAN provides the terminal with an MBMS bearer service using a radio bearer (RB). A point-to-point RB is a bi-directional RB and includes a logical channel DTCH (dedicated traffic channel), a transport channel DCH (dedicated channel) and a physical channel DPCH (dedicated physical channel) or a physical channel SCCPCH (secondary common control physical channel). A point-to-multipoint RB is a uni-directional downlink RB and includes a logical channel MTCH (MBMS traffic channel), a transport channel FACH (forward access channel) and a physical channel SCCPCH. The logical channel MTCH is configured for each MBMS service provided to a cell, and is used to send user plane data related to a specific MBMS service to a plurality of terminals.
By using a multicast service notification procedure, the UTRAN performs a counting function to count the number of terminals that intend to receive a specific multicast service within a specific cell. The counting function is used to determine whether an RB providing a specific multicast service is set as point-to-multipoint or to point-to-point. When the number of terminals existing in the corresponding cell is smaller than a threshold value, the UTRAN sets a point-to-point RB. However, when the number of terminals existing in the corresponding cell is greater than the threshold value, the UTRAN sets a point-to-multipoint RB.
When the point-to-point RB is set with respect to a specific service, all the terminals that intend to receive the service enter an RRC connected state. However, if a point-to-multipoint RB is set with respect to a specific service, the terminals that intend to receive that service may not enter an RRC connected state. Furthermore, a terminal in an RRC idle state may receive a multicast service through the point-to-multipoint RB.
In the multicast service, the UTRAN uses a counting function to determine whether to set a point-to-multipoint RB or a point-to-point RB. The selection of a radio bearer type through the counting function may enable efficient use of radio resources. The counting function is performed periodically before the multicast service or during the multicast service. The terminal in the idle state performs an RRC connection establishment procedure with the UTRAN after receiving service notification, such that the UTRAN counts the number of terminals. After the service notification, the UTRAN counts the number of terminals that intend to receive a specific multicast service within a cell upon receiving SGSN (serving GPRS support node) information associated with terminals having an RRC connection. The RB type of a multicast service may thereby be determined.
Once the RB type is determined, the UTRAN performs control such that a certain number of terminals receive a corresponding service in an RRC connected state according to a state of radio resources, and certain other terminals receive the corresponding service in an RRC idle state.
As described above, the UTRAN performs a counting procedure to determine an RB type for a specific MBMS service. In such a counting procedure, a terminal sends an RRC connection request message to the UTRAN to establish an RRC connection and to notify the UTRAN that it wants to receive the specific MBMS service, thereby providing information required by the UTRAN to determine an RB for the specific MBMS service.
The UTRAN determines an RB for a specific service by a cell unit. Accordingly, the UTRAN performs a counting procedure per cell unit, meaning that the UTRAN may not perform the counting procedure according to circumstances and characteristics of a specific cell, and also meaning that when an RB is established for one cell, information from another cell is not necessary.
Also, during an RRC connection request procedure, the terminal continues sending an RRC connection request message to the UTRAN to establish an RRC connection until completing the RRC connection establishment or receiving an RRC connection rejection message.
In one example, it is assumed that cell A is a service area of MBMS service 1 and cell B is not a service area of the MBMS service 1. The service area is a region in which a corresponding service is available. Additionally, it is assumed that the terminal stays in cell A.
Accordingly, when MBMS service 1 begins, cell A performs a counting procedure. Because the terminal staying in cell A wants to receive MBMS service 1, the terminal sends an RRC connection request message to the UTRAN in response to the counting procedure. It is further assumed that the terminal moves to cell B while waiting for the reception of a response message to an RRC connection request from the UTRAN.
According to the related art operation, the terminal once again constructs an RRC connection request message in cell B and sends the message to the UTRAN. However, because cell B is not a service area of MBMS service 1, the terminal may not receive the corresponding MBMS service in cell B.
Nonetheless, the terminal sends an RRC connection request message in cell B where the MBMS service is not available. Accordingly, an uplink common channel may become congested due to unnecessary transmission of RRC connection request messages. Furthermore, if the RRC connection is established, radio resources of cell B may be wasted and the terminal may waste battery power by maintaining an RRC connection longer than necessary.